deps: make the sqlx TLS backend selectable - #967

coverage: 73.18% (-2.0%) from 75.203% — feldera:sqlx-aws-lc-rs-main into supabase:main

Yeah, I think the rationale makes sense, but there are a few cases that need to be fixed before this is ready:

• In etl, make each TLS feature enable the same feature on etl-postgres.
• In etl-maintenance, replace the hardcoded ring feature with selectable ring/AWS-LC features, and pass the selected feature to etl.
• In etl-destinations, pass the selected feature to etl and, when DuckLake is enabled, to etl-maintenance.
• In the workspace binaries and examples, explicitly select ring on the ETL dependencies so they preserve the current behavior.
• Add an AWS-LC-only CI check with default features disabled. It should also verify that the SQLx ring feature is absent; --all-features enables both and ends up testing ring.

There is also one compatibility question. Today, default-features = false still includes SQLx TLS because the TLS feature is enabled directly on the SQLx dependency. After this PR, the same configuration would build without TLS unless the user explicitly selects a provider.

I think the no-provider configuration should fail at compile time instead of silently building ETL without TLS. For etl, I mean a check along these lines:

#[cfg(not(any(
    feature = "tls-rustls-ring",
    feature = "tls-rustls-aws-lc-rs",
)))]
compile_error!(
    "Either `tls-rustls-ring` or `tls-rustls-aws-lc-rs` must be enabled."
);

Direct etl-postgres users should get the same protection when the SQLx store is enabled:

#[cfg(all(
    feature = "store",
    not(any(
        feature = "tls-rustls-ring",
        feature = "tls-rustls-aws-lc-rs",
    )),
))]
compile_error!(
    "Either `tls-rustls-ring` or `tls-rustls-aws-lc-rs` must be enabled when `store` is enabled."
);

This would be a breaking change for users with default-features = false: their existing build would stop until they select one of the two providers. The failure and the required fix would at least be explicit, rather than changing the TLS behavior silently.

@iambriccardo, wdyt? Is requiring those users to select a TLS provider an acceptable breaking change? If yes, I think the compile-time checks plus documenting the required feature are the safest way to handle it. If not, I don't think this design can both preserve the old behavior and support an AWS-LC-only build.

I think this is a fair change to do. We are currently in alpha phase, so breaking changes are expected.

@farazdagi sorry for the delay, please have another look at the PR which now should include your changes requested